providers/perplexity/provider_test.go (1)

81-90: Strengthen empty-key test with header assertion.

TestNew_EmptyKey should also verify no Authorization header is injected when the API key is empty.

✅ Suggested test extension

 func TestNew_EmptyKey(t *testing.T) {
 	provider, err := New("")
 	if err != nil {
 		t.Fatalf("unexpected error: %v", err)
 	}
@@
 	if provider.Name() != "perplexity" {
 		t.Errorf("Name = %q, want %q", provider.Name(), "perplexity")
 	}
+
+	req := httptest.NewRequest("POST", "https://api.perplexity.ai/v1/sonar", nil)
+	if err := provider.RequestEnricher().Enrich(req, llmproxy.BodyMetadata{}, nil); err != nil {
+		t.Fatalf("unexpected error: %v", err)
+	}
+	if got := req.Header.Get("Authorization"); got != "" {
+		t.Errorf("Authorization = %q, want empty", got)
+	}
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@providers/perplexity/provider_test.go` around lines 81 - 90, Extend
TestNew_EmptyKey to assert that no Authorization header is sent when the API key
is empty: create an httptest.Server whose handler fails the test if
r.Header.Get("Authorization") is non-empty, then create the provider with
New(""), make a request to that server using the provider's HTTP client (use
provider.client or provider.httpClient if available, otherwise construct the
request the provider would send and call http.DefaultClient.Do) and verify the
server handler was invoked without an Authorization header; keep the existing
Name() assertion intact.

providers/perplexity/resolver.go (1)

13-15: The nil check suggestion is defensive programming only—not a bug fix.

The Perplexity Resolver is exclusively instantiated via NewResolver(), which parses the base URL and returns an error if parsing fails. The Provider.New() constructor propagates this error, meaning Resolve() is never reachable with a nil or uninitialized receiver in practice. Other resolver implementations in the codebase (openai_compatible, googleai, bedrock, azure) use the same pattern without nil guards.

If defensive nil checks are desired for robustness, consider applying them consistently across all resolver implementations rather than in isolation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@providers/perplexity/resolver.go` around lines 13 - 15, Do not add a solitary
nil-receiver guard inside Resolver.Resolve; keep the current implementation
returning r.BaseURL.JoinPath("v1", "sonar"), nil as-is because Resolver is
constructed via NewResolver() and Provider.New() already enforces valid BaseURL;
if you do want defensive nil checks, apply the same pattern consistently to all
resolver types (e.g., Resolver.Resolve, openai_compatible resolver, googleai
resolver, bedrock resolver, azure resolver) and implement identical nil checks
and error returns across their Resolve methods so behavior is uniform.